Computing platforms for developing and maintaining software generally rely on one of two kinds of systems: non-module systems and module systems.
A non-module system refers to a system in which dependencies between different pieces of code are not strictly declared or restricted. An industry-defined term “JAR hell” refers to example uses of Java Archive (JAR) files in a non-module system which result in problems, for example, with the class loading process.
A module system includes a collection of standard modules and defines how the collection of standard modules work together. Each particular standard module in the collection of standard modules may explicitly define dependencies on other standard modules (or the contents thereof). However, standard modules are typically restricted from explicitly depending on any non-module code.
FIG. 1A illustrates a system 100 with components of a module environment 102 and components of a non-module environment 130. The non-module environment 130 includes non-module code 132-146. Dependencies between different non-module code are not required to be explicitly declared. Accordingly, when a first non-module code depends on a second non-module code, the software development environment must search for the second non-module code in all files of a set of files associated with all of the code. The dependencies between different non-module code (which may not be explicitly declared) are illustrated in FIG. 1A using arrows. For example, the dependency of non-module code 132 on non-module code 140 is illustrated using an arrow beginning at non-module code 132 and ending at non-module code 140. Furthermore, a dependency of non-module code 140 on non-module code 142 and non-module code 144 is illustrated using two arrow beginning at non-module code 140 and ending at non-module code 142 and non-module code 144, respectively.
The module environment 102 includes a set of standard modules (e.g., standard modules 104-112). Dependencies between different standard modules in a module environment, such as module environment 102, are explicitly declared by the modules. An explicitly declared dependency may be referred to herein as an “explicit dependency.” The explicit dependencies between different standard modules (or contents thereof) in module environment 102 are also illustrated using arrows. For example, the explicit dependency of standard module 104 on standard module 108 is illustrated using an arrow starting at standard module 104 and ending at standard module 108. Further, the explicit dependency of standard module 108 on standard module 110 is illustrated using an arrow starting at standard module 108 and ending at standard module 110.
As illustrated in FIG. 1A, there is a partition between module environment 102 and non-module environment 130. Specifically, standard modules cannot explicitly depend on non-module code. For example, standard module 110 cannot explicitly depend on either non-module code 132 or on non-module code 134. As a result, module environments comprising standard modules cannot be built on top of non-module environments comprising non-module code. The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.